More and more computing applications are being migrated to cloud environments, in which resources of a provider network are typically deployed to provide a variety of multi-tenant and/or single-tenant services to large numbers of users. Provider network resources may support a number of basic infrastructure services providing virtual or physical compute servers, storage devices, networking devices and the like, as well as more complex layered services built on top of the basic services. One service may provide virtualized compute servers, for example, another may provide block storage volumes, another may provide key-value based storage objects, while other services may utilize such more basic infrastructure-oriented services to provide more complex entities such as load-balanced compute/storage clusters or farms, relational or non-relational database servers, content-distribution services, private networks in the cloud, and the like.
A given client may often utilize a number of different provider network services, and may in some cases have hundreds or even thousands of different, often-interrelated resources allocated at a given time. Some resources may be associated with a multiplicity of services—e.g., a client may obtain a networking resource such as a virtual network interface from one service, and deploy that virtual network interface for a database provided by another service. Similarly, a given storage resource acquired by a client may be utilized concurrently for storing data associated with several different services.
At least in some provider network environments, user interfaces such as web-based consoles are typically provided to enable clients to view and administer aspects of the services they are using, and the resources that have been allocated to them. Such consoles and other similar tools are often designed to focus primarily on a single service, however. Users of such interfaces may have to switch back and forth between different consoles or other interfaces as they try to manage their services and resources usage. Often, especially as the number of resources associated with a client account increases, it may not be easy to obtain an intuitive big-picture view of the services in use by, and the resources assigned to, the client account.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.